其實去年就想這一系列，但是就怕寫完變成別人的線上課程，所以沒有寫 (想太多了)
想了一年之後，還是覺得不要留什麼招在自己的內心，這樣才是對自己有信心的表現
因為工程師的價值並不是做了什麼，而是為什麼這麼做，對吧！

從需求、觀念到功能

在學習 Vue.js 的路上，我從語法開始學習，從傳遞、更新資料的方式，也有拿來做過去 jQuery 常做的抽換 class。

但是初學一開始，比起用 jQuery 很難從頭寫一個頁面，不知道存在 data 中的值如何使用，只是跟著官網的範例寫了一個 count++

Object-oriented programming

過往寫過一陣子的 C++，所以對於 OO 有著一種執著，但是自從寫了 JS 之後就不再這樣了。
對於 OO 還是有著一定的觀念。

封裝 + 繼承 + 動態連結 = 物件導向

這也是 JS 很不 OO 的由來，不過後來 JS 有導入 private variable 了，所以，應該也算是補齊了最後一塊拼圖了。

Private class features - JavaScript | MDN

這些觀念用在 Vue 上依然非常好用。

functional programming

在學習 Vue 的過程，也有學習一些 React，所以會跟 React 的框架學習一些觀念。
只是認識這些觀念的過程，總是會遇到一些「λ狂熱信徒」，不過也是因為這些信徒的熱情介紹，讓我認識許多關鍵字，有助於我對 Vue 框架使用。

• immutable: 資料不更新，只有替換資料
• pure function: function 的輸出只跟輸入有關
• higher order function: function 當參數傳遞進來 HOF，會產生新的 function
• currying: 可以執行到一半的 function

這些是我用在 Vue 上面的 functional programming，也許還有其它的...

達到 MVVM 效果的自動化魔法 computed 和 watch

當需求裡面有資料同步連動並更新畫面時，第一個反應就是這兩個選一個上場！方便又有效！
但真的是這樣嗎？

Computed Properties and Watchers — Vue.js

學習 Vue 的過程，第一個關卡就就是要認識 computed 和 watch 這兩個新東西，總是讓人混亂不已，總覺得 watch 就是 computed + data ，不知道要選哪一個比較適合當下面對的問題。

watch API — Vue.js

對 watch 的更新，如果物件太深，就會失效，也不知道多深才會出問題，但總是用 deep: true 似乎也不是辦法？

切分 component 切太多記不住？！

不知道什麼樣的需求，要切分 component，還是畫面太複雜時，就切一下。
究竟是要怎麼切才是合理的，component 的 component 太深怎麼每一次都會吃掉我大部份的認知負擔，是不是 component 不可以太深？還是有其它的問題？

表單綁定神器: 魔法 attribute v-model 但省了什麼 code

需求提到表單填寫時，就會想用 v-model，似乎是表單麻煩事的必備良方。

Form Input Bindings — Vue.js

v-model 似乎可以讓 template (html) 的寫法變得簡潔，但是 v-model 加上 computed 的時候，會讓 get/set 的寫法一直反覆出現，卻又不能合併，好像也是無法改變的事情。

Two-way Computed Property, Form Handling | Vuex

在 vuex 中有提到使用了 v-model 和 computed 的做法，可以讓畫面直接綁到 state，但這樣寫會讓 code 變多！閱讀失去了魔法的 v-mode 就覺得很多贅 code！

失控 component 與暴量的 attribute, event

需求的畫面很複雜時，就是要切分 component，但是每個 component 之間的溝通就是讓人頭大，每次有 bug 時就不知道在哪一層出現問題，用了 Vue 好像和用 jQuery 沒什麼差別只是換了一個工具，開發的麻煩性也沒有變少。

v-bind Shorthand, Template Syntax — Vue.js
Props — Vue.js

v-on Shorthand, Template Syntax — Vue.js
Custom Events — Vue.js

有了 component ，進入了一個可以自己定義 html 的標籤的夢幻自由國度，什麼都可以抽出來，又什麼都可以傳出來。

Custom Events — Vue.js
.sync Modifier, Custom Events — Vue.js

必要時每個 prop 都可以雙向綁定成 v-model, prop.sync(v2), v-model:prop(v3) 這樣做用起來很清爽，不用看見成對的 prop/event。
但是當我的 component 有二十個欄位難道我要一個一個綁嗎？(累！)
不可以傳入之後，直接在 component 裡面修改值就好了嗎？一定要傳出來？

頓時間讓自己無所適從，每次寫 vue 要切 component 都不知道要怎麼做 prop/event 才會真正讓自己覺得省下一些工夫，而不是每一次都在做苦工。

我的 component 不是我的 component

用 Vue 更換畫面等同於更換 component 只是這個 component 的畫面比較大。那要用哪個技術抽換呢？這個有一定嗎？還是不管是什麼，通通用 vue route 就對了？是嗎？

Conditional Rendering — Vue.js
keep-alive with Dynamic Components, Dynamic & Async Components — Vue.js
Getting Started | Vue Router

在 vue 中換 component 有幾種方式

1. 用 v-if 和變數
2. 用 <component :is=""> 和變數
3. 用 <router-view> 和 router

這幾種方式和需求之間的距離有多遠？
好像選哪一種都沒差 component 都會抽換

vue-router

等到拿來做專案時，就配合不同的需求、畫面，試著分類 component 並且透過 axios 取得資料，從這開始就出現了一些混亂的情況，API 呼叫混亂，axios 引入的位置也沒有一定的規則

API 收到 403 時，要怎麼優雅的請畫面跳轉到登入頁

vuex

使用 vuex 管資料，一開始就覺得只是將 data 移到 state 而已。mutate 和 getters 似乎也沒有什麼特別的用途，若資料沒有要改變，似乎也不用特別寫。

邏輯寫在 aciton 和 mutation 好像也沒有什麼差別。也許只要寫 action 和 state 就好。

以上，如果你已經寫了一段時間的 vue ，而且有任何一個一樣的想法，請一定要追這一個連載，以上這些覺得沒有差別的想法，就會造成一些 random coding 的產出

從需求判斷資料讀寫需求

從現代前端工程師該如何聆聽需求，請務必在需求訪談時，特別注意「資料讀寫」的情境。這些情境就是我們要處理的條件判斷。
「資料讀寫」這個角度去探討，畫面元件設計與資料編輯權限的相關性，配合其它程式設計的理論，建構出一個前端框架使用的思考流程。

如果你有上述的困難，請訂閱這一系列。這一系列會 (希望可以) 帶著你的思緒思考，運用技術的過程，如何寫出好維護、自我文件化、縮小 bug 範圍、好追縱錯誤的程式碼 (希望看完的人不會覺得我在胡說八道。哈哈)。